Zoom 2/Zoom - Release 2 (1996)(Active Software)[!].iso/texts/amoszine/arts/po_how_do.asc

Text File | 1992-09-02 | 8KB | 164 lines

      @2
                      H O W   D O   T H E Y   D O   T H A T ?
      @6
                                      by
      @3
                                   Paul Overy.
      @4

      So what's this new section all about?
      @1
      Basically I'm going to attempt to explain techniques used in full
      priced games, giving you a deeper knowledge into games programming.
      I decided to write this column as there many techniques spread over
      a wide area of games, & like all good idea's kept secret giving game
      companies the upper hand.  But all is not lost.  Just by looking
      carefully the way its code operates, you can tell with a curtain
      accuracy how it was written.
      Even if a resulting method does not use the same techniques as one
      you were trying to emulate, who cares as long as its fast & can
      compete with standards today.  You may just have come up with a
      better routine.

      While I've got your attention, if you would like the basis of a game
      explained then write to:-
      @3
                                 Paul Overy
                                 27 Barton Road
                                 Maidstone
                                 Kent
                                 ME15 7BU
                                 England
      @1
      Hopefully your answer will be in the next issue of the Amoszine.

      @5
      Time to take apart same games.
      @4
      I'll be looking at Project X, Zool, OverDrive & Micro Machines.

      @2
      Project X.
      @1This is one high class game, using the very best in Amiga
      techniques.

      Your ship & side shots are 16 colour sprites animated at full 50fps.

      i.e.  One Ship = 32*32 pixel sprite.
            Two Side shots 16*64(maybe larger) pixel sprites.
      @1NOTE:The two side shots are a good choice for the use of sprites, as
      it can be of any length of a lowres screen.

      All other ships weapons included missiles are at 25fps, & are
      animated as bobs.

      Other attacking crafts, which are bobs animated at 25fps including
      power ups.  Looking at the game I would say the only objects at full
      frame rate would be the fast moving background stars (pixels) & the
      3 sprites defined above.  The fast moving stars flicker as would real
      ones, but I think this is because they are drawn last & so sometimes
      miss syncronisation with the screen.

      The Large moving background screen is scrolled at 25fps, I
      measured this buy marking off 320 pixels and timing a staring & end
      point.  The result from this was about 11-12 seconds, which indicates
      a steady frame rate of 25fps.
      i.e.  320/25 = 12.8 (which is close to my time by hand timer)

      The background scroll appears to be 32cols, and uses maximum
      overscan.  The game employees screen offsetting on the y-axis to
      give a up & down scroll motion on the ships vertical movements.
      They probably also use the same kind of scroll method as my
      Swap-Scrolly (fully documented in AZ2), although as the screen
      scrolls at a constant rate in the same direction this is very much
      easier to do.  The screen is probably moved in 32 different sections
      in the background over 2 frames, & is displayed every other frame
      buy which time all the sections have been moved.  This above
      method is if they updated the borders every 16 pixels, meaning they
      only need to move a block of 9 pixels in height & screen width every
      frame.  If borders were updated every 32pixels then an even higher
      number of cutting sections could be used,64 in total for even less
      drain on CPU time.

      @2
      Zool.
      @1
      Just a quicky on this one, but never the less is still & very good
      technique to used in almost any game.

      The well used doppel-ganger effect, allowing two Zool characters on
      screen when you hit a power up.
      Two objects can be displayed at no extra cost, as each is displayed
      on a different frame.  So no extra time is taken up, although the
      characters do flash as they can't both be on the screen at the same
      time.  But this flashing looks as if its meant to be there giving a
      invisible type of effect.  A Good technique to use when you have no
      more spare sprites.

      @2
      Micro Machines
      @1
      This has to be one of the easiest games to write, as it uses a simple
      scroll algo.  How cant people say this 16 col scroll, 4 col car game is
      better then the 32 col scroll, 16 col car game Overdrive!

      It uses a 16 pixel boundary update & the screen in moved in one go
      on every boundary update.  In-between  this the screen is offset in
      the correct direction to give a scroll effect.  Very lazy.
      Because of the nature of the scroll there is hardly any time left to
      update any bobs, the only extra object apart from sprites in the game
      is a black blob used for a shadow effect for when the cars jump.
      As very title update time is left only the sprites can now be used.
      They needed to used all eight of the 16*16 pixels sprites, resulting in
      only being able to use 4 colours sprites. (yuk)
      So 4 sprites are used as cars & the left over's for the dust marks
      when a car turns a tight corner.

      Wow this games so hard to write, I've given you example code.
      (see Micro_Machines.Amos but you will need the Turbo extension)

      @2
      OverDrive
      @1
      This is more like it, a car game that has actually been programmed
      with full use of the Amiga's hardware.

      I think their method of scrolling is very close to mine, again see
      Swap-Scroll in Amoszine 2.
      Your car is a 16 colour sprite, 32x32 pixels with the spare sprites
      being used as smoke/dust rings.
      They somehow managed to display two cars on screen as bobs, this
      must have been really critical as updating these bobs must of socked
      up ever spare bit of game time, otherwise they would of gone for 4
      cars on screen.

      You may have noticed that when turning in a full circle the scroll
      engine moves the screen in a square shape, so the car has to be
      moved from the centre point to correct this lack in scroll.
      Which in my opinion looks rather nice, backing up my assumptions
      of their scroll method.  As my own scroll method can't move off at
      a angle if the border is not lying on a 16 pixel boundary.

      Why this strange square movement scroll?
      Well Team-17 are using an advanced scroll method, which can't
      scroll off at an angle while the border boundary lie outside the 16 or

      32 pixel boundary.
      So this square movement enforces this, so & all that needs to be
      done is to re-centre the car once the true scroll is underway.


      @3
      That's it, no more ideas for this issue.
      @5
      Don't forget to write to me if you have any questions on games, I deal
      with anything from adding two numbers to ray-casting.
      @1
      I say..."Doom can be done on the Amiga"
      You will just have to have it in black and white & turn the monitor on
      its side so all the screen writes are byte aligned, also using the
      hardware vertical line scan to help convert your data.
      Either that or re-solder your chip memory for non-sequential writes,
      meaning one write will be treated as parallel, placing information of
      each bit plane on number of chips in one go.